Financial portfolio management system and method

ABSTRACT

A financial portfolio management system operable in a network environment can be configured to gather financial information from a plurality of sources over an electronic network and intelligently aggregate the information into a financial portfolio viewable by a client. The client can determine which accounts should be included in the portfolio. The system uses web crawling, parsing, or spidering technology to update the portfolio information. The system provides one platform that conveys financial information from a variety of accounts held at several different financial institutions.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/618,253 filed on Nov. 13, 2009, which is a continuation of U.S.patent application Ser. No. 09/881,959 filed on Jun. 15, 2001, whichclaims the benefit of priority to U.S. Provisional Patent ApplicationNo. 60/217,443, filed on Jul. 10, 2000. The entirety of each of theabove-referenced patent applications is hereby incorporated byreference.

FIELD OF THE INVENTION

The present invention relates generally to data gathering and managementusing communication networks, such as, the Internet. More particularly,an exemplary embodiment of the present invention relates to a system forand method of managing financial portfolios over a communicationnetwork.

BACKGROUND OF THE INVENTION

The tremendous growth of technology has positively affected the growthof financial markets. For example, technologies, such as, communicationsystems and networks have enabled investors to access a veritableplethora of information and carry out a variety of transactionsinvolving financial markets. Such financial information can be gathered,distributed, and acted upon much faster and more efficiently than everbefore. Prior to communication systems and networks, such as, theInternet, mechanisms for gathering and consolidating information fromfinancial institutions were slow and inefficient.

Even today, financial institutions do not use a single standardinterface, data format, or communication protocol to provide andexchange financial data on-line. Investors who want a single source ofportfolio information have to move all of their assets to a single largeinvestment industry vendor. However, such large vendors may notnecessarily offer simple, easy access and a single source for financialinformation. Furthermore, despite the availability of “one-shop”institutions, many investors do not want to use a single institutionbecause diversification across many institutions allows investors to getthe “best” offerings from a variety of vendors.

Thus, as the marketplace shifts toward greater control by theself-directed investor, there is a need to provide financial vendorswith tools and services that attract and retain investors. Further,there is a need for vendors to provide investors with the ability toautomatically gather financial information from any number of financialinstitutions. Even further, there is a need for investor-orientedportfolio data consolidation.

Heretofore, conventional computer applications have been commerciallyavailable which provide what can be called either desktop financialpackages or financial statement consolidators. For example, desktopfinancial packages, such as, QUICKEN sold by Intuit, Inc. of MountainView, Calif., and MONEY or MSN INVESTOR, both sold by MicrosoftCorporation of Redmond, Wash., allow users to perform calculations onfinancial information and present the financial information and anycalculation results. However, conventional desktop financial packagesare limited to only downloading information from direct data connectionswith individual remote locations, such as, an individual financialinstitution. Further, such desktop financial packages only handlespecific data, formats and do little, if anything, to relate downloadedfinancial information.

As another example, financial statement consolidators, such as Yodlee,Inc. of Redwood City, Calif., and GreenTrack Investments of NewRochelle, N.Y., gather information about accounts and re-present thatinformation as if the financial institutions had issued a commonstatement. However, such consolidators do not manipulate the informationbecause it all has a common format before it is gathered. The financialinformation is only re-presented.

Thus, there is a need for a financial portfolio management system whichprovides access to financial information from a variety of unrelatedfinancial sources. Further, there is a need to normalize and integratefinancial information from various financial sources as to providemeaningful and accurate information. Even further, there is a need toaggregate financial information in a way that provides relationshipsamong the financial information.

SUMMARY OF THE INVENTION

An exemplary embodiment is related to a financial portfolio managementcomputer-implemented method for providing access to financialinformation of customers of financial institutions. The financialinformation can originate from financial sources including a number offinancial institutions. This method can include the steps of gatheringfinancial information associated with a client from the financialsources, normalizing the financial information from the financialsources into a single normalized data format, aggregating the financialinformation into a financial portfolio, and conveying informationassociated with the financial portfolio to the client. The financialsources can include at least one financial institution and the financialinformation is stored in at least one data format.

Another exemplary embodiment is related to a financial portfoliomanagement system operable in a network environment. This system caninclude means for gathering client-specific electronic financialinformation from sources over an electronic network, means fornormalizing the client-specific financial information into a singlenormalized data format, means for intelligently aggregating theclient-specific financial information into a financial portfolio, andmeans for conveying information associated with the financial portfolioto the client. The financial information is stored in at least one of aplurality of data formats, and the financial information is associatedwith a client.

Another exemplary embodiment is related to a user interface configuredto allow a client to view and modify financial portfolio informationgathered from a plurality of financial sources. The plurality offinancial sources can include a number of unrelated financialinstitutions. The user interface can include means for presentingfinancial account information of a client where the financial accountinformation is associated with at least one of a plurality of financialinstitutions, means for presenting information for at least one of aplurality of financial securities, and means for presenting a value fromthe financial account information with at least one of a plurality offinancial institutions.

Another exemplary embodiment is related to a method of enabling accessto financial information over a network. This method can include using afirst processing system to maintain a financial information processingunit, receiving a signal for invoking the financial informationprocessing unit from a remote processing system via a network, and usingthe first processing system to operate the financial informationprocessing unit in response to the signal. The financial informationprocessing unit receives and processes requests for financialinformation associated with a number of unrelated financialinstitutions. The signal for invoking the financial informationprocessing unit is transmitted from the remote processing system inresponse to a selection of a hypermedia link.

Another exemplary embodiment relates to a method of enabling access tofinancial information over a network in a local processing system. Themethod includes the steps of receiving a request from a first remoteprocessing system via a network and, in response to receiving therequest, transmitting to the first remote processing system over thenetwork information for enabling the first remote processing system tooutput a financial information interface to a user. The financialinformation interface includes financial information for a number offinancial institutions and is configured to enable the user to requestspecific financial information for a financial institution. The requestis generated by the first remote processing system according to ahypermedia link provided to the first remote processing system from aseparate processing system on the network.

Another exemplary embodiment relates to a processing system including acentral processing unit (CPU) and a storage device coupled to aprocessor and having stored there information for configuring the CPU.The CPU can be configured to maintain a financial information processingunit corresponding to a single client and financial institutionsmaintaining accounts for the client. This financial informationprocessing unit is configured to provide a user interface for enablingthe client to submit requests for information on financial informationof the financial institutions and configured to receive and process therequests. The CPU can also be configured to receive a request forinvoking the financial information processing unit from a remoteprocessing system via a network. This request is transmitted from theremote processing system in response to a selection of a hypertext linkby the user. The CPU can further be configured to operate the financialinformation processing unit in response to the request.

Another exemplary embodiment relates to an apparatus for enabling accessto financial information from a plurality of unrelated financialinstitutions over a network. This apparatus can include means forreceiving a signal from a remote processing system via the network. Thissignal is transmitted from the remote processing system in response to aselection of a hypermedia link by a client. The hypermedia link can beprovided by a web site of a financial institution and can specify afinancial information aggregator. The apparatus can also include meansfor invoking a financial information processing unit in a localprocessing system in response to the signal. The means for invoking caninclude providing information for generating a user interface for accessto financial information from the financial information aggregator. Thefinancial information processing unit is configured to receive andprocess requests for financial information.

Other principle features and advantages of the invention will becomeapparent to those skilled in the art upon review of the followingdrawings, the detailed description, and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The exemplary embodiments will hereafter be described with reference tothe accompanying drawings, wherein like numerals denote like elements,and:

FIG. 1 is a general diagrammatical representation of a portfolio managerconnected to a communications network;

FIG. 2 is a general functional block diagram of an exemplary embodimentof the portfolio manager of FIG. 1;

FIG. 3 is a flow diagram of steps in a financial portfolio integrationprocess in accordance with an exemplary embodiment;

FIG. 4 is a general functional block diagram of exemplary operationalcomponents of the portfolio manager of FIG. 1;

FIG. 5 is a general functional block diagram of an exemplary embodimentof an application service component of the portfolio manager of FIG. 1;

FIG. 6 is an exemplary user interface display conveying information fromthe portfolio manager of FIG. 1;

FIG. 7 is an exemplary user interface display conveying information fromthe portfolio manager of FIG. 1;

FIG. 8 is an exemplary user interface display conveying information fromthe portfolio manager of FIG. 1;

FIG. 9 is an exemplary user interface display conveying information fromthe portfolio manager of FIG. 1;

FIG. 10 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1;

FIG. 11 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1;

FIG. 12 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1;

FIG. 13 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1;

FIG. 14 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1;

FIG. 15 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1;

FIG. 16 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1; and

FIG. 17 is an exemplary user interface display conveying informationfrom the portfolio manager of FIG. 1.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

A system for and method of managing financial portfolio information overa communication network are described. In the following description, forpurposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the present invention. Itwill be evident, however, to one skilled in the art that the exemplaryembodiments may be practiced without these specific details. In otherinstances, structures and devices are shown in block diagram form inorder to facilitate description of the exemplary embodiments.

In one embodiment, a computer system is used which has a centralprocessing unit (CPU) that executes sequences of instructions containedin a memory. More specifically, execution of the sequences ofinstructions causes the CPU to perform steps, which are described below.The instructions may be loaded into a random access memory (RAM) forexecution by the CPU from a read-only memory (ROM), a mass storagedevice, or some other persistent storage. In other embodiments,hardwired circuitry may be used in place of, or in combination with,software instructions to implement the functions described. Thus, theembodiments described herein are not limited to any specific combinationof hardware circuitry and software, nor to any particular source for theinstructions executed by the computer system.

FIG. 1 illustrates a connection between a portfolio manager 10 and anetwork 20. Portfolio manager 10 provides access to financialinformation available via network 20. In an exemplary embodiment,network 20 is the Internet, a worldwide network of computer networksthat use various protocols to facilitate data transmission and exchange.Network 20 can use a protocol, such as, the TCP/IP network protocol orthe DECnet, X.25, and UDP protocols. In alternative embodiments, network20 is any type of network, such as, a virtual private network (VPN), anEthernet, or a Netware network. Further, network 20 can include aconfiguration, such as, a wide area network (WAN) or a local areanetwork (LAN). Network 20 preferably provides communication withHypertext Markup Language (HTML) Web pages 30 and 40. Web pages 30 and40 include a variety of data on a variety of Web servers. Network 20also provides communication with a communication network portal 50 whichcouples computers 52 and 54 and a service 56 including a database 58 tonetwork 20. Service 56 is any type of company, content or serviceprovider with a connection to network 20. Database 58 is a storagemedium for data and may be an optical, magnetic, or any other suitablestorage medium.

Generally, portfolio manager 10 can be implemented using a computerserver configured by software. Preferably, the server includesread/write memory, such as, disc drives and other storage. A customer orclient can access portfolio manager 10 via a web page 30 or 40 which isconveyed to the client at computer 52 or 54. Computers 52 or 54 can beany type of computing device, including work stations, laptops,notebooks, personal digital assistants (PDAs), cell phones, beepers, orother equipment capable of communication with network 20. In anotherembodiment, portfolio manager 10 can be accessed via telephones, suchas, a cell phone 12 or a standard telephone 14. Other user interfaceplatforms may also be provided for using portfolio manager 10. Such userinterface platforms include, for example, WAP (wireless applicationprotocol) and web interfaces.

Advantageously, portfolio manager 10 provides a portfolio managementservice that draws investors or their representatives to web sites offinancial service vendors, such as, asset managers, brokerage firms,information portals, and research firms. Portfolio manager 10 enablesinvestors or their representatives to work with data from all on-lineaccounts within a single managed software application. Further,portfolio manager 10 benefits financial service vendors by providingneeded comprehensive financial planning and analysis tools to web sitesof financial service vendors. These added tools result in greaterattraction and retention of investors and provides a basis for whichinvestors will frequent the web site of a vendor.

In an exemplary embodiment, portfolio manager 10 is embedded in the website of a financial vendor. As such, portfolio manager 10 can helpattract and retain investors to the web site of the financial vendor,significantly increasing the frequency, duration, and quality of visitsby the investor to the web site.

In an exemplary embodiment, portfolio manager 10 employs web crawlingand parsing technology to obtain data from other web sites andautomatically updates portfolios on a daily or more frequent basis.Portfolio manager 10 gathers information from a variety of institutions,whether or not those institutions support a standard data format. Suchinformation is encrypted and securely stored at a hosting facility ofportfolio manager 10. Advantageously, the parsing technology permitsportfolio manager 10 to support a variety of aggregation needs withoutspecial arrangements or prior approval from financial vendors.

In an exemplary embodiment, portfolio manager 10 includes an interfaceimplemented as a JAVA applet. The applet provides quick delivery ofinformation to the client and no loss of context when switching betweendata views. The applet is also designed to accommodate vendor web sitecolor schemes and branding. The applet can also be configured withhypertext links to vendor tools/web sites and can also be configured topass security, position, account, and portfolio information to theapplication or page at the other end of the hypertext link, integratingthe applications and allowing them to cooperate.

Portfolio manager 10 can include a sophisticated web crawler thatgathers account data from financial institutions by parsing data fromfinancial institutions, including data in formats, such as, HypertextMarkup Language (HTML), Open Financial Exchange (OFX), QuickenInterchanged Format (QIF), and ASCII files having tab- orcomma-delimited values (e.g., a format suitable for importing intospreadsheet applications). Portfolio manager 10 can also directlyconnect to data servers, such as OFX servers and back-office accountingsystems, without relying on web crawling or similar techniques.

FIG. 2 illustrates a general functional block diagram 200 of portfoliomanager 10 (described with reference to FIG. 1), in accordance withanother exemplary embodiment. As shown in diagram 200, data network 210is communicatively connected to a financial information gatherer 220.Financial information gatherer 220 can be a computer program configuredto automatically retrieve financial information over network 20.Alternatively, financial information gatherer 220 can be a person whoreceives paper statements or views a web site and transcribes the data.

Financial information gatherer 220 receives financial information fromany of a variety of financial institutions. For example, financialinstitutions can include credit unions, banking institutions, stockexchanges, portfolio managing companies, or any of a variety of otherinstitutions which may provide a source for financial information. In anexemplary embodiment, financial information from different financialinstitutions can be available in different data formats. Different dataformats means that financial information may be stored in HTML, QIF, orother data structure formats.

Financial information gatherer 220 can obtain a variety of differentdata or information from different account types and in a variety ofdifferent file transfer formats. Table 1 below provides examplefinancial sources and corresponding example account types, data, andfile transfer formats.

TABLE 1 File Transfer Financial Source Account Types Data CollectedFormat Retail Banking Checking Balances OFX Savings Transactions QIFMoney Market HTML CD Cash Reserve Retail Trading Holdings OFX AssetShareholder Balances HTML Management Plan Participant TransactionsTrusts/Wealth Trusts Holdings CSV, etc Management Private ClientBalances HTML Private Banking Transactions

Financial information gatherer 220 communicates financial information toa financial information normalizer 230. Financial information normalizer230 receives raw financial information in a variety of different formatsand converts the raw financial information into a normalized format. Anormalized format is one which financial information from differentsources is nevertheless consistent.

By way of example, as an exchange standard, the OFX data format defineshow the “total” for a buy or sell transaction is identified, but itimposes no limits on the amount itself (e.g., is that total positive ornegative). Similar situations exist with balances and with transaction °identification. For instance, OFX defines a means to report balances,but does not require that the actual cash in an account be identified orreported in any specific way. Further, OFX defines a way fortransactions to be given unique identifiers, but does not require thatthe financial institution use the same identifier for the transactioneach time the transaction is retrieved. The OFX scope is also limited tothe retail banking and retail asset management arenas. OFX makes noprovision for more sophisticated financial issues, such as, positioncost basis, tax lot identification, or the division between principaland income portions of a trust. Furthermore, even where OFX iswell-defined, actual usage may deviate from OFX guidelines.Advantageously, portfolio manager 10 can work with such deviations tonormalize and integrate all available financial data.

Normalization by financial information normalizer 230 takes elements ofthe raw data and assigns them to appropriate places or “positions” in adata model. This normalization process largely “standardizes” thenon-standard formats, while also addresses some of the issues inherentin the standard formats.

Financial information normalizer 230 communicates the normalizedfinancial information to a financial portfolio integrator 240. Financialportfolio integrator 240 collects financial information associated witha client into a portfolio. A plurality of financial portfolios can beprovided. Such portfolios can include security holdings, savings andchecking information, mutual funds, and other financial data. Financialportfolio integrator 240 can communicate a portfolio to a financialportfolio presenter 250 for conveyance to the client. For example, theportfolio can be conveyed to the client via displays, such as, thedisplays described with reference to FIGS. 6-15.

In an exemplary embodiment, financial portfolio integrator 240 uses aseries of heuristics and algorithms to evaluate the financial data,respond to inconsistencies and gaps, and combine that data with othersources of information (e.g., third-party data sources, previouslyretrieved information, and user-supplied/manual input) to produce acomplete data picture. Preferably, the integration process learns overtime, and is adapted to the idiosyncrasies of new financial institutiondata sources as they are brought on board.

Advantageously, financial portfolio integrator 240 processes data intoricher, more consistent formats. Such integration can involveinterpretation of free-form data to answer questions, such as, to whatinstrument does the data refer; what kind of activity does it represent;and what are the relevant values? Integration can also involvereconciliation, answering questions, such as, is this “real” accountinformation or an error; has this information been seen before; and howdoes this relate to everything else? Integration can involveadjustments, answering questions, such as, what are the implications forother positions; and what are the implications for cash flows?

Financial portfolio integrator 240 decide how normalized data fits intothe data model of portfolio manager 10. For example, over 18 terms areused to indicate a “buy” transaction. These can include “automaticinvestment”, “automatic purchase”, “BOT”, “bought”, “buy”,“contribution”, “direct investment”, “direct purchase”, “EECON”,“invested”, “investment”, “money fund sweep”, and other terms. Financialportfolio integrator 240 identifies differences in semantics to avoidloss of critical information and is instrumented to detect and reportsituations where decisions cannot be made or where those decisionsappear to be incorrect based on other data available from other sources.

Financial portfolio integrator 240 applies business logic, interpretingand categorizing financial information, enabling portfolio manager 10 toprovide value-added portfolio management tools. Examples of businesslogic can include asset class categorization, sub-asset classcategorization, comparison of actual to target allocation, computationof allocation adjustment, personal return calculations, net worthhistory, e-mail alerts (e.g., daily security activity, holding“issues”), and portfolio metrics (e.g., portfolio level return;portfolio risk/volatility).

Advantageously, the process described with reference to FIG. 2automatically brings together the financial information data of oneclient from any of a multitude of financial institutions, regardless ofthe data formats used by the financial institutions and regardless ofthe relationships between financial institutions.

FIG. 3 illustrates a flow diagram 300 of exemplary steps in a financialportfolio integration process. Flow diagram 300 depicts one process bywhich financial portfolio integrator 240 described with reference toFIG. 2 operates. In an exemplary embodiment, a step 310 is performed inwhich raw or parsed financial data 313 is examined to determine whetherthere are missing pieces of data. If there are missing pieces of data, acontext-free description interpreter 315 is engaged.

Context-free description interpreter 315 applies variouslanguage-processing techniques, such as, recognition of numbers andsymbols with special meaning, to extract missing information from thedescription. As an example, some financial institutions provide an“incomplete” set of data elements and pack the remaining informationinto a description. The institution might report something like:

Trade date: Jan. 3, 2001

Settle date: Jan. 6, 2001

Ticker: QCOM

Description: Buy 100 shares @$65/share

Total: $6,500

In this example, transaction type, units/quantity and unit price are notprovided as separate data elements, but are desired by a data model usedby portfolio manager 10. The above description is broken into tokens“BUY”, “100 SHARES”, and “@ $65/SHARE”. A dictionary can be used toidentify “BUY” as an activity type, pattern matching and a dictionarycan be used to identify “100 SHARES” as a quantity of 100, and morepattern matching can be used to identify “@ $65/SHARE” as a unit priceof $65.

Free-text descriptions in context-free description interpreter 315 canbe unlimited by nature, and a term may have several possible meanings,depending on context (e.g., the word “INCOME” may indicate an activitytype, as in “INCOME RECEIVED”, or may be part of a name, as in “GROWTHAND INCOME FUND”). A context-sensitive description interpreter(described below) can handle descriptions not handled by context-freedescription interpreter 315.

If data is not missing in step 310 or after context-free descriptioninterpreter 315 is engaged, a step 320 can be performed in which adetermination is made as to whether there are multi-part values in thefinancial data. If multi-part values are present, a value combiner 325is engaged. Value combiner 325 can handle the situation where afinancial information source (e.g., a web site) divides totals intoincome and principal portions. These portions need to be combined toproduce a total. Value combiner 325 can also handle the situations wherea financial information source provides multiple activity descriptions.For example, a financial institution can present the transactioninformation provided in Table 2 below.

TABLE 2 Transaction Type Activity Type Amount Dividends/Gains CashReceipt $17.50 Dividends/Gains Purchase ($17.50) Contributions CashReceipt $50.00

Value combiner 325 can use a rule-based mechanism to take the“transaction type” information and the “activity type” information andproduce a single type for each of the three transactions (e.g., Income,Buy, and Deposit, respectively). Value combiner 325 can also handle thesituations, such as, a balance conflict by adding the OFX-specifiedelements of AVAILCASH and MARGINBALANCE together, watching for specificfree-form balance entries and using these to adjust that result further(e.g., “MARGIN ACCOUNT EQUITY” is subtracted, adjusting for the use ofMARGINBALANCE to report the total value of a margin account).

If there are not multi-part values in step 320 or after value combiner325 is engaged, a data record filter 335 can be engaged. Recordsdownloaded from financial institutions may hold transactions, but theyalso may hold summary information (e.g., subtotal/total rows, such asone might have in a spreadsheet) or status information (e.g., the onlyrecord in a table may be “system not available”). Data record filter 335can use rules with a combination of statistics (e.g., does a recordcontain the elements “expected” based both on other records/columnheaders seen and on data model requirements) and a dictionary (e.g.,does the record look like it refers to a known-to-be-uninteresting typeof data) to eliminate records deemed to be of no value. At the sametime, data record filter 335 can preserve status information, marking itas a “status” transaction (as opposed to balance, holding, or activity)so later processing can mark the account appropriately. Data recordfilter 335 results in filtered data 337.

Filtered data 337 and name/quote data 343 are provided to an equityidentifier 345. Financial institutions identify instruments by Ticker,CUSIP (identification number selected by the Committee on UniformSecurities Identification Procedures), or name (which may beabbreviated) identifiers. The identification may be free-standing, ormay be embedded in a free-text description. Equity identifier 345 isresponsible for identifying the equity associated with a transaction. ACUSIP can look like quantities and other numerical values. It is used inthe absence of a ticker and only if the CUSIP is clearly identified bythe financial institution (via a label of some sort). Where a CUSIP isused, equity identifier 345 looks the CUSIP up in a database of equitiesand uses the resulting Ticker.

Equity identifier 345 can use a variety of techniques to identify anequity. For example, equity identifier 345 can check to determinewhether the name is a ticker name or a name-in-database as well aschecking the description contains a ticker or name-in-database. If anequity is not identified, equity identifier 345 can incorporate theinstitution's name (because mutual fund companies often do not includetheir name with the fund name, while the rest of the world does). Forexample, the SCUDDER Internet web site might list “Global Fund”, whileall non-SCUDDER sources call it “Scudder Global Fund”.

Equity identifier 345 can use smart handling to identify situationswhere common names are used to identify instruments that do notcorrespond to what other sources would expect. For example, an insurancecompany may name a variable annuity after a mutual fund on which theannuity is based. A successful identification requires that theinstrument's NAV (net asset value) correspond to the price reported bythe financial institution (within tolerances) for a successful match.This identification technique can be expanded beyond mutual funds to anyname to avoid potential incorrect identification from free-form names.

After equity identifier 345 is engaged, previous position data 353 anddata from equity identifier 345 can be provided to a position identifier355. Position identifier 355 can determine to which existing position inthe data model of portfolio manager 10 a transaction corresponds. To doso, position identifier 355 can rely on equity-based and name-basedmatching.

After position identifier 355 is engaged, a context-sensitivedescription interpreter 365 can be engaged. Transactions with missinginformation and free-text descriptions can be interpreted again in lightof the account's known positions. Context sensitive descriptioninterpreter 365 can compare the descriptions to the names of theaccount's positions (or the names/tickers of the associated equities)and attempt to find a point at which to break the description intocomponents, much as numbers and special symbols were used incontext-free description interpreter 315, described above. If thedescription can be broken down, similar techniques to those describedearlier can be used to extract data values. Success may cause positionidentifier 355 to be re-engaged.

After context sensitive description interpreter 365 is engaged, a valueadjuster 375 can be engaged. Value adjuster 375 can correct values(e.g., adjusting signage to conform to the data model) and supplymissing values based on information in the transaction and knowledge ofthe equity. For example, given any two of unit price, quantity, andtotal, the missing element can be calculated. If unit price is missingbut the equity is known, the unit price can be supplied.

After value adjuster 375 is engaged, a step 380 can be performed inwhich a decision is made whether a transaction identifier (ID) ismissing. If the transaction ID is missing, a transaction ID generator382 can be engaged. Transaction ID generator 382 generates a unique IDfor the transaction by combining a representation of all of its dataelements (e.g., date, amount, account, equity, etc.).

If the transaction ID is not missing or after the transaction IDgenerator 382 is engaged, a duplicate eliminator 385 can be engaged.Duplicate eliminator 385 can manage multiple copies of the sameinformation. In the case of holding and balance information, duplicateeliminator 385 deletes any older information from the same day (holdinginformation is not “final” until the close of the business day, so laterinformation is better). In the case of activity information, duplicateeliminator 385 deletes the new copy, as the older copies will have beenprocessed already, and the information about a transaction never changes(any changes are posted via “corrections”, which are new transactions).

After duplicate eliminator 385 is engaged, a position adjuster 387 canbe engaged. Position adjuster 387 can create, update, and/or deletepositions based on the new transactions. Position adjuster 387 may alsocombine multi-part holdings into a single entity. Examples can includecombining a trust's holding of a single equity reported as separate“principal” and “income” holdings into a single position, combiningmultiple pieces of an overall cash balance into a single balancerepresenting all of the cash in the account, and combining holdings of asingle equity bought using different techniques (e.g., bought using cashvs. bought on margin) into a single position.

After position adjuster 387 is engaged, a step 390 can be performed inwhich a determination is made as to whether a position in the data modelof portfolio manager 10 is missing or, in other words, the position withwhich a transaction being processed is associated has not beenidentified. If a position is missing, an orphan handler 392 is engaged.It is possible that some transactions remain without having anidentified position. Orphan handler 392 provides an attempt to assignthese transactions to a position. In an exemplary embodiment, orphanhandler 392 identifies transactions that do not carry equity informationwith them, checking their type for applicability to a cash transaction,and associating those transactions with the account's cash balance.

After orphan handler 392 is engaged, a step 393 can be performed inwhich a determination is made as to whether a position is discovered. Ifa position is discovered, context-sensitive description interpreter 365is engaged. If a position is not discovered or if a position is notdetermined to be missing in step 390, a cash flow adjuster 395 can beengaged. The arrival of new transaction information may haveimplications on cash flows for various historical periods. Cash flowadjuster 395 can map newly processed transactions with non-neutral cashflow implications to the periods covering each transaction's date andrecalculates the flow for that period. The result of cash flow adjuster395 is personalized data 397. Personalized data 397 is used in theformation or updating of a financial portfolio file.

Advantageously, the financial portfolio integration process describedwith reference to FIG. 3 intelligently aggregates financial informationinto a financial portfolio. Such integration allows forinter-relationships among financial information to be established.Further, the integration provides an automated processing of financialinformation such that calculations, projections, and other operationscan be performed on the data included in the information.

FIG. 4 illustrates a general functional block diagram 400 of exemplaryoperational components of portfolio manager 10 described with referenceto FIG. 1, in accordance with yet another exemplary embodiment. As shownin diagram 400, a web browser 410 can include an applet application 412.Applet application 412 is configured to communicate with a web server420. In an exemplary embodiment, applet application 412 provides datapresentation and user interaction and is written in the JAVA programminglanguage.

Web server 420 can include a servlet application 422. Servletapplication 422 is configured to communicate with an application servicecomponent 430. Servlet application 422 provides data access and requestprocessing/dispatching by interacting with the client-side applet 412,and can be written in the JAVA programming language. Servlet application422 can be accessed via a secure (HTTPS) uniform resource locator (URL),using Secure Sockets Layer (SSL) support of web server 420.

Application service component 430 can include an equity update agent432, business logic 434, and a spider agent 436. Application servicecomponent 430 provides security and account data acquisition andinterpretation. Equity update agent 432 can communicate with a quoteserver 440 and an equity information database 450. Equity update agent432 is a module responsible for interacting with third party quoteservice to obtain security information. Quote server 440 is a servercomputer which is configured to provide equity pricing information(e.g., information obtained from financial exchanges and other thirdparty data providers). Equity information database 450 is a databasethat contains information on equity (e.g., stock, bond, mutual funds)obtained from third party quote services.

Business logic 434 can communicate with equity information database 450,a login information database 460, and a portfolio information database470. Business logic 434 is a module responsible for performingtransaction interpretation, rate of return calculations, and any otherdata processing required by portfolio manager 10. Login informationdatabase 460 is a database which contains login identifications andpasswords/PINs, obtained from users, for each on-line account, if theuser opts to allow portfolio manager 10 to gather and update accountinformation automatically. Portfolio information database 470 is adatabase which contains user and portfolio information, populated with acombination of user-supplied information, data obtained from financialinstitutions, and results of calculations made by business logic 434.Spider agent 436 can communicate with portfolio information database 470and financial institutions 480, 482, and 484. In an exemplaryembodiment, spider agent 436 is a module responsible for crawlingfinancial institution sites for account data.

In an exemplary embodiment, the following scenarios are illustrative ofthe interaction of components of portfolio manager 10 during operation.Servlet application 422 can receive a user registration request eitherfrom applet application 412 or from a separate vendor web page. Servletapplication 422 connects to the login information database 460 to createan account for the client. If this request does not come directly fromthe client, the password is pre-expired. The client can request creationof a portfolio, or registration of an account, while running appletapplication 412. Applet application 412 collects all requiredinformation and sends the information along with a “stored new data”request to servlet application 422. Servlet application 422 receives therequest and its information and hands the package off to a new thread.This thread stores the information in the login information database 460and portfolio information database 470.

In an exemplary embodiment, if the user is registering an account andopts not to have a personal identification number (PIN) informationstored by server 420, the login information is not transmitted to server420, but rather is stored locally by applet application 412.

In an exemplary embodiment, nightly spidering takes place on behalf ofall clients, without a specific client request to drive it. Applicationservice component 430 maintains a spidering schedule. When the timearrives for nightly spidering, spider agent 436 of application servicecomponent 430, first, finds the accounts it is to handle; second,consults login information database 460 and makes a list of thoseaccounts for which it also has login information; and third, distributesthis list among a set of spidering threads.

Each spidering thread connects to the appropriate financial institution,performs a log-in procedure using the login information supplied to it,and then downloads the information for the specified account. Theresults are handed off to a data parser that interprets the downloadeddata and writes transaction and holding information to portfolioinformation database 470. Once information from an account has beenupdated, spider agent 436 notifies business logic 434, which looks upthe account (from portfolio information database 470), processes anynewly downloaded transactions, and writes the results of itscalculations back to portfolio information database 470. Business logic434 also evaluates any alerts associated with the portfolio of theaccount and generates and delivers any required electronic mail bycontacting a SMTP server to do so.

In an exemplary embodiment where spidering is initiated upon a requestby the client and PIN information is located on the server, thefollowing may be performed. Where the client is working in appletapplication 412 and requests and an account update, applet application412 checks the PIN storage policy of the client, sees that PINs arestored on the server, and sends an “on-demand spidering” request toservlet application 422, identifying the client who's accounts are to bespidered. Servlet application 422 hands this package to a new thread,which simply passes the request and its parameters through toapplication service component 430. The thread of servlet application 422sends an acknowledgement back to applet application 412 and issues aperiodic series of “progress” responses based on information it getsperiodically from application service component 430. Spider agent 436identifies that the request contains no account or login information andlooks up the information from login information database 460 andportfolio information database 470. Processing then proceeds as it doesduring nightly spidering.

In an exemplary embodiment where the client requests spidering and PINsare located on the client, applet application 412 checks a list ofclient account information, looks up login and PIN information from alocal database or memory device. Applet application 412 then sends thisfull list and an “on-demand spidering” request to servlet application422. Servlet application 422 handles this request the same way ithandles other on-demand spider requests.

FIG. 5 illustrates a general functional block diagram 500 of anexemplary embodiment of application service component 430 described withreference to FIG. 4. Application service component 430 includes a mainserver, spider agent, equity update agent, and business logic. The mainserver can include a controller 512 and an error logger 514. Spideragent can include a dispatcher 522, financial institution (FI) datacollectors 524, a data buffer queue 526, and a data parser 528. Theequity update agent can include a quote collector 532 and a newscollector 534. The business logic can include a transaction interpreter542, a return calculator 544, and an alert generator 546.

Controller 512 handles update scheduling and on-demand processingrequests, passing them along to the appropriate component to which therequests correspond. Error logger 514 generates an error notification,which is a service available to all components of application servicecomponent 430. Dispatcher 522 accepts spidering requests from controller512. Dispatcher 522 starts and monitors H data collector 524 for eachfinancial institution and/or account involved, eliminating the number ofconcurrent threads based on server parameters. Dispatcher 522 readsinformation from a login information database and passes thisinformation to FI collectors 524. Dispatcher 522 also accepts log-ininformation passed from an applet application using a local PIN databasethrough the servlet application to application service component 430.

FI data collectors 524 are responsible for contacting a financialinstitution and downloading account data as requested by dispatcher 522.FI data collectors 524 build a buffer of raw data and place it on databuffer queue 526. Several FI data collectors 524 may be active at thesame time. Data buffer queue 526 serves as a coordination point betweenFI data collectors 524 which fill queue 526 and data parser 528, whichempties queue 526. In an exemplary embodiment, data buffer queue 526 isan in-memory, thread-safe repository of data buffers. Data parser 528 isresponsible for translating raw financial institution data and turningit into data objects and records with a common format and storing theresults in a database.

Quote collector 532 is responsible for interacting with a third partyquote service, such as, North American Quotations of London, Ontario,Canada, to gather security information and update records in the equityinformation database 450. News collector 534 is responsible forinteracting with a third party news service, such as Reuters, gatheringarticles and news releases and updating records in equity informationdatabase 450.

Transaction interpreter 542 is responsible for reading unprocessedtransactions from portfolio information database 470 and using thisinformation to adjust holding information, such as cost basis, andnumbers of shares, and writing any results back to portfolio informationdatabase 470. Transaction interpreter 542 may consult the securityinformation database for information about securities referred to by thetransactions. To avoid the performance hit of polling for unprocessedtransactions, the database access responsible for creating anunprocessed transaction “pings” or sends a communication to thetransaction interpreter 542 to let it know there are transactions to beprocessed. Return calculator 544 is responsible for calculating internalrates of return for holdings and portfolios. Return calculator 544 readsinformation from both portfolio information database 470 and equityinformation database 450 and updates portfolio information database 470.Information from databases 450, 460 and 470 can be accessed through adatabase access 537. Alert generator 546 is responsible for evaluatingportfolio and holding changes and generating alerts. Alerts can bestored in portfolio information database 470 and are also sent to anSMTP mail server for delivery as e-mail messages.

FIG. 6 illustrates an exemplary user interface display 600 conveyinginformation from portfolio manager 10 (FIG. 1). Display 600 includesinformation associated with financial markets, such as, the Dow JonesIndustrial Average market index. Display 600 also includes informationregarding specific stocks held by the client or being watched by theclient. Further, display 600 includes information regarding fundamentalsand alerts specific to a selected stock.

In an exemplary embodiment, display 600 includes a section 610 depictinga graphical representation of financial market information. A section620 can include a list of security holdings arranged by ticker symbol,including the security price daily change, and volume of transactions inthe financial market. A section 630 in display 600 shows additionalinformation about a particular security selected in section 620.

FIG. 7 illustrates an exemplary user interface display 700 conveyinginformation from portfolio manager 10 (FIG. 1). Display 700 providesinformation regarding total net worth of the client. Total net worth caninclude information regarding the total value of each portfolio andaccount, the value of any other assets the client may hold, and theamount of any liabilities owed by the client. Further, display 700 caninclude a graph of the client's net worth as it changes over time, aswell as detailed information regarding values of specific holdings,values of asset classes of holdings, and values of asset subclasses ofholdings within accounts and portfolios.

FIG. 8 illustrates an exemplary user interface display 800 conveyinginformation from portfolio manager 10 (FIG. 1). Display 800 displaysinformation regarding the risk and return for selected holdings in theportfolio of the client. Risk and return can be shown in display 800graphically as well as textually.

FIG. 9 illustrates an exemplary user interface display 900 conveyinginformation from portfolio manager 10 (FIG. 1). Display 900 includesinformation on a financial portfolio. Display 900 also includes agraphical display of actual value and target value for the portfolio.

FIG. 10 illustrates an exemplary user interface display 1000 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1000 includesinformation on transactions for a financial portfolio. Display 900 alsoincludes transaction details for a selected transaction.

FIG. 11 illustrates an exemplary user interface display 1100 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1100 includesset up information for a financial portfolio. Display 1100 also providesfor the input of personal information from the user of portfolio manager10.

FIG. 12 illustrates an exemplary user interface display 1200 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1200 includesset up information for a financial portfolio. Display 1100 also providesfor the selection, creation, and comparison of portfolios from the userof portfolio manager 10.

FIG. 13 illustrates an exemplary user interface display 1300 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1300 includesset up information for a financial portfolio. Display 1300 provides forthe input of assets and liabilities in a portfolio from the user ofportfolio manager 10.

FIG. 14 illustrates an exemplary user interface display 1400 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1400 includesset up information for a financial portfolio. Display 1400 provides forthe input of ticker names to watch from the user of portfolio manager10.

FIG. 15 illustrates an exemplary user interface display 1500 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1500 includesset up information for a financial portfolio. Display 1500 provides forthe input of financial alerts from the user of portfolio manager 10.

FIG. 16 illustrates an exemplary user interface display 1600 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1600 includesbasic holding information for a financial portfolio. Display 1600provides a graphical and numerical representation of holdingsallocations in the financial portfolio.

FIG. 17 illustrates an exemplary user interface display 1700 conveyinginformation from portfolio manager 10 (FIG. 1). Display 1700 includesmore detailed holding information for a financial portfolio than display1600 described with reference to FIG. 16. Display 1700 provides agraphical and numerical representation of holdings allocations as wellas target allocations for a financial portfolio.

Advantageously, portfolio manager 10 provides total information access,bringing all customer financial data from any bank, brokerage, or otherinstitution in one place. Further, portfolio manager 10 makes it easyfor customers to see their portfolio performance at any time withautomatic updates. Portfolio manager 10 allows customers to customizeand organize portfolios and help understand risk and return withadvanced analysis tools. Further, portfolio manager 10 helps attract andretain key customers with the added value of portfolio manager 10.Portfolio manager 10 allows customers co-branding and custom links toproducts and services available from specific financial institutions.

Portfolio manager 10 can include the ability to share data at twolevels, such as, at a client level and at a financial intermediarylevel. At a client level, portfolio manager 10 provides individuals withfinancial information that may be from multiple financial sources. At anintermediary level, such as brokers, financial advisors, andaccountants, portfolio manager 10 provides financial servicesintermediaries with a tool for assisting customers in the management oftheir financial portfolio.

Advantageously, customers can track all of their assets and liabilitiesand monitor their net worth in one place. Portfolio manager 10 helpscustomers to set and monitor personal investment goals. Portfoliomanager 10 assists in evaluating return relative to risk information,allowing customers to make smarter decisions on investments.

While the exemplary embodiments illustrated in the figures and describedabove are presently preferred, it should be understood that theseembodiments are offered by way of example only. Other embodiments mayinclude, for example, a wide variety of ways to convey financialportfolio information, such as, wireless application protocol (WAP),personal digital assistant (PDA) protocols, and other presentationmeans. Further, while exemplary embodiments describe the invention inthe context of financial assets, the invention may extend to otherassets or other items which can be organized into a portfolio. Theinvention is not limited to a particular embodiment, but extends tovarious modifications, combinations, and permutations that neverthelessfall within the scope and spirit of the appended claims.

What is claimed is:
 1. A system for manipulating financial information,comprising: a central processing unit (CPU); and a storage devicecoupled to the CPU and having stored there information for configuringthe CPU to: retrieve financial information of a customer by connectingover a network to each of two or more unrelated financial institutions,at least one of the two or more unrelated financial institutions storingits financial information in a data format different than at least oneother of two or more unrelated financial institutions stores itsfinancial information; for each of two or more unrelated financialinstitutions, normalize the retrieved financial information into asingle normalized data format by assigning each piece of the customer'sretrieved financial information to a different position in a stored datamodel; and generate a financial portfolio by aggregating financialinformation.
 2. The system of claim 1 wherein the aggregating comprisesapplying at least one language-processing technique to address one ormore missing pieces of financial information.
 3. The system of claim 2wherein the at least one language-processing technique comprises acontext-free analysis or a context-sensitive analysis.
 4. The system ofclaim 1 wherein the aggregating comprises identifying and interpretingthe retrieved financial information.
 5. The system of claim 2 whereinthe aggregating further comprises identifying and interpreting theretrieved financial information and the addressed one or more pieces offinancial information.
 6. The system of claim 1 wherein the aggregatingcomprises combining two or more pieces of financial information into asingle piece of financial information.
 7. The system of claim 1 whereinthe network is the Internet and wherein the retrieving includes the useof a secure communication protocol.
 8. The system of claim 1 wherein theretrieving includes at least one of web crawling, parsing, and spideringtechnology.
 9. The system of claim 1 wherein the retrieving includesautomatically performing a login procedure for at least one of the twoor more unrelated financial institutions and downloading informationfrom each of the two or more unrelated financial institutions.
 10. Thesystem of claim 1 further configuring the CPU to receive a communicationfrom a client computer to initiate a display of at least some of thegenerated financial portfolio.
 11. The system of claim 7 furtherconfiguring the CPU to communicate the at least some of the generatedfinancial portfolio to the client computer for display to a client astext and graphics.
 12. A computer-readable medium storing software coderepresenting instructions that when executed by a computing system causethe computing system to perform a method of manipulating financialinformation, the method comprising: retrieving financial information ofa customer by connecting over a network to each of two or more unrelatedfinancial institutions, at least one of the two or more unrelatedfinancial institutions storing its financial information in a dataformat different than at least one other of two or more unrelatedfinancial institutions stores its financial information; for each of thetwo or more unrelated financial institutions, normalizing the retrievedfinancial information into a single normalized data format by assigningeach piece of the customer's retrieved financial information to adifferent position in a stored data model; and generating a financialportfolio by aggregating financial information.
 13. Thecomputer-readable medium of claim 12 wherein the aggregating stepcomprises applying at least one language-processing technique to addressone or more missing pieces of financial information.
 14. The system ofclaim 13 wherein the at least one language-processing techniquecomprises a context-free analysis or a context-sensitive analysis. 15.The system of claim 12 wherein the aggregating step comprisesidentifying and interpreting the retrieved financial information. 16.The system of claim 13 wherein the aggregating step further comprisesidentifying and interpreting the retrieved financial information and theaddressed one or more pieces of financial information.
 17. The system ofclaim 12 wherein the aggregating step comprises combining two or morepieces of financial information into a single piece of financialinformation.
 18. The computer-readable medium of claim 12 wherein thenetwork is the Internet and wherein the retrieving step includes the useof a secure communication protocol.
 19. The computer-readable medium ofclaim 12 wherein the retrieving step includes at least one of webcrawling, parsing, and spidering technology.
 20. The computer-readablemedium of claim 12 wherein the retrieving step includes automaticallyperforming a login procedure for at least one of the two or moreunrelated financial institutions and downloading information from eachof the two or more unrelated financial institutions.
 21. Thecomputer-readable medium of claim 12 wherein the method furthercomprises receiving a communication from a client's computer to initiatethe displaying.
 22. The computer-readable medium of claim 21 wherein themethod further comprises communicating the at least some of thegenerated financial portfolio to the client's computer for display to aclient as text and graphics.
 23. A system for manipulating financialinformation, comprising: a central processing unit (CPU); and a storagedevice coupled to the CPU and having stored there information forconfiguring the CPU to: retrieve financial information of a customer byconnecting over a network to each of two or more unrelated financialinstitutions, at least one of the two or more unrelated financialinstitutions storing its financial information in a data formatdifferent than at least one other of two or more unrelated financialinstitutions stores its financial information; for each of two or moreunrelated financial institutions, normalize the retrieved financialinformation; and generate a financial portfolio by aggregating financialinformation, the aggregating comprises applying at least onelanguage-processing technique to address one or more missing pieces offinancial information.
 24. The system of claim 23 wherein thenormalizing includes normalizing the retrieved financial informationinto a single normalized data format by assigning each piece of thecustomer's retrieved financial information to a different position in astored data model.
 25. The system of claim 23 wherein the at least onelanguage-processing technique comprises a context-free analysis or acontext-sensitive analysis.
 26. The system of claim 23 wherein theaggregating further comprises identifying and interpreting at least oneof the retrieved financial information and the addressed one or morepieces of financial information.
 27. The system of claim 23 wherein theaggregating further comprises combining two or more pieces of financialinformation into a single piece of financial information.
 28. The systemof claim 23 wherein the network is the Internet and wherein theretrieving includes the use of a secure communication protocol.
 29. Thesystem of claim 23 wherein the retrieving includes at least one of webcrawling, parsing, and spidering technology.
 30. The system of claim 23wherein the retrieving includes automatically performing a loginprocedure for at least one of the two or more unrelated financialinstitutions and downloading information from each of the two or moreunrelated financial institutions.
 31. The system of claim 23 furtherconfiguring the CPU to receive a communication from a client computer toinitiate a display of at least some of the generated financialportfolio.
 32. The system of claim 23 further configuring the CPU tocommunicate the at least some of the generated financial portfolio tothe client computer for display to a client as text and graphics.